Zero the external array buffer before it is written to the file - #335

Not every byte of an Hdf5ExternalArray buffer gets set before the buffer is
flushed.  The bottom segment "length" field never is -- lengths are derived
from the next segment's start position, so nothing writes it and nothing
reads it -- and the buffer comes from new char[], so whatever the allocator
last had there is serialised into the file.

The result is that two runs producing the same alignment write different
files.  It showed up as heap garbage in element 0 of a genome's BOTTOM_ARRAY:
one run had 0, another had 7378429340001763376, whose bytes spell out a
fragment of a sequence name left over in freed memory.  Only the first buffer
is affected in a fresh file, since page() reads every later window back and
hdf5 returns its fill value for regions never written.

Zero it in initBuf() so it covers load() as well as create().  A file opened
for modification reaches its arrays through Hdf5Genome::read(), which loads
them, and segments are then written through those buffers -- zeroing only on
the create() path leaves uninitialised bytes in the merged output of
halAppendSubtree.

Beyond reproducibility this stops process memory leaking into a shared file,
and lets h5diff and checksums be used to compare two hal files meaningfully.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017E9w7KrbFEfqNRtkam4u1F